home *** CD-ROM | disk | FTP | other *** search
/ TPUG - Toronto PET Users Group / TPUG Users Group CD / TPUG Users Group CD.iso / AMIGA / (A)TB / (A)TBM.ADF / Utilities / bootmenu.doc < prev    next >
Text File  |  1991-04-20  |  10KB  |  235 lines
  1. BootMenu v1.0
  2. By J davis
  3. 09/1990
  4.  
  5.  
  6. Synopsis
  7. --------
  8.  
  9. Bootmenu - a program to allow graphical, interactive selection of
  10. NTSC/PAL screen modes and the enabling/disabling of hard-disks on
  11. every reboot. Also acts as a partial replacement for CBM's setpatch
  12. program. Includes source code in Assembler. Version 1.0 (first
  13. release). Author - John Davis
  14.  
  15. Purpose
  16. -------
  17.  
  18. BootMenu serves three purposes :-
  19.  
  20. Firstly it allows you to disable your auto-configing hard-disk (and
  21. all other auto-config devices) so as to minimise the chances of a
  22. virus or trojan horse attacking your hard-disk when booting of a game
  23. disk, and also to help with running some games/demos that won't run
  24. with a hard-disk active.
  25.  
  26. Secondly, for people with the 1mb Fat Agnus (8372), it offers a
  27. choice of NTSC and PAL screen modes. PAL is useful for in the USA, as
  28. it offers a 25% increase in screen area (at the expense of being
  29. incompatible with NTSC  genlocks etc), whilst NTSC is useful for the
  30. rest of the world, as a lot of games are written for NTSC sized
  31. screens, and the graphics only display the correct aspect ratio in
  32. NTSC mode ( F/A-18 has to be the best example of this, playing
  33. F/A-18 on a PAL screen gives you a very 'squished' looking plane!)
  34.  
  35. Thirdly, it acts as an improved version of CBM's 'setpatch r' for
  36. people with 1mb of chip memory. CBM's reboot handler will only
  37. survive ONE reboot, meaning that if you use RAD, reboot off a floppy
  38. and then reboot again, the contents of rad: are GONE!!! The reboot
  39. handler this installs is much more reliable - it will only fail if
  40. exec is so damaged the machine _must_ coldboot.
  41.  
  42. What's more, since it 'wedges' itself into the system you only need
  43. to load it once - it will survive reboots, which is handy if you're
  44. playing several games in a row and don't want to have to re-boot off
  45. the hard-disk to reselect screen mode, all you do is reboot and
  46. BootMenu will let you select system options once again.
  47.  
  48. Installation
  49. ------------
  50.  
  51. Just run BootMenu - either from the CLI or WorkBench (there's an icon
  52. provided, though it's no artistic masterpiece - I'm a programmer, not
  53. an artist). You should get a message saying that it's installed ok.
  54.  
  55. IMPORTANT - do NOT run the WorkBench1.3.2 Setpatch program with the
  56. 'r' option (option to patch for rad: and 1mb ram) after you have run
  57. BootMenu, as both use the same vector, and hence SetPatch will
  58. disable BootMenu! You should run Setpatch _without_ the 'r' option!!
  59.  
  60. Also see the section 'virus checkers and BootMenu'
  61.  
  62. Usage
  63. -----
  64.  
  65. Once it's installed, the next time you reboot you should be presented
  66. with a menu screen asking whether or not to turn off all the
  67. machine's expansion boards. Click the left button to select 'on'
  68. - this will leave your hard-disk, expansion memory etc enabled, or
  69. click the right button to select 'off' and turn off all the boards.
  70. If you don't make any selection within 10 seconds, the program will
  71. default to the 'no' option and leave all your boards turned on.
  72.  
  73. If you've got a 1mb Obese Agnus fitted, you'll then be presented with
  74. a second screen, allowing a choice of PAL screen modes (click left
  75. button) or NTSC (click right button). Again, if no choice is made
  76. within 10 seconds the program will default to PAL.
  77.  
  78. The machine will then carry on it's normal boot sequence ....
  79.  
  80. Technical Info
  81. --------------
  82.  
  83. This program uses BOTH a coldcapture and coolcapture handler to do
  84. it's work.
  85.  
  86. The coldcapture handler is simply used to fix the KickStart1.x bug
  87. regarding 1mb of chip mem. The bug is that ks1.x treats any amount of
  88. chip memory greater than 512k as abnormal, and will do a total cold
  89. reboot, clearing any cold/cool handlers. Our cold-handler fixes this
  90. bug in the ROM, mainly so as to make our cool-handler actually get a
  91. chance to run, but as an added bonus it also acts as an improved
  92. version of setpatch with the 'r' option.
  93.  
  94. The trouble with the CBM 'setpatch r' is that it doesn't stick around
  95. - the coldcapture vector they (and I) use gets cleared after use,
  96. hence if you want to survive multiple reboots you need to re-insert
  97. yourself into the system. Setpatch fails to do this and hence can
  98. fail to protect rad: if you reboot twice in a row without reloading
  99. setpatch. We DO reinsert ourselves, so unless the system is totally
  100. rebooted (as will happen if you get serious enough memory corruption
  101. from a guru, or from some games), BootMenu should protect rad:.
  102.  
  103.        Moral of the story - use BootMenu instead of setpatch r!!!
  104.   Note also that you should ONLY use BootMenu with KickStart 1.x!!!!
  105.   The main code for running the screens etc is hung off the
  106.   coolcapture vector. Being on coolcapture as opposed to coldcapture
  107.   allows us to access much more of the system, as most of the machine
  108.   is setup by the time coolcapture runs (this is important if we want
  109.   to access exec.library functions such as addmem)
  110.  
  111. The menu driver runs all the hardware direct (intuition isn't in a
  112. usable state when coolcapture runs), using the window controls so as
  113. to make each screen only take up 1k for it's bitmap as opposed to the
  114. usual 21k. All screens are only 1 plane deep (to conserve memory).
  115. The copper is used to run the screen itself, and also to get more
  116. than 1 colour off the 1 plane screen (reloading the palette on a
  117. per-scanline basis)
  118.  
  119. The 'core' of bootmenu (approx 2.5k of code, of which 2k is the
  120. bitmaps for the display, the actual code fits in approx 512k bytes!)
  121. installs onto the bottom of the system stack, to avoid having to use
  122. kickmemptr to keep our memory allocated. As the system stack is 6k,
  123. and only 1k is normally used this shouldn't be a problem (bootmenu
  124. uses the opposite end of the stack - there's still at least 2k free).
  125.   If worse comes to worse and the system stack grows large (due to
  126. nested exceptions), all that will happen will be that BootMenu is
  127. overwritten - it will not cause the system to lock up in normal
  128. operation.
  129.  
  130. As we can't guarantee the system stack will be in chip mem, the
  131. screen data and copper list is swapped into and out of chip memory
  132. (swapping preserves the original memory contents - in case rad: was
  133. somehow using the target memory ). I haven't tested the effect of
  134. using MoveSSP (a PD program which places the system stack in fast
  135. ram) but I would guess it's use would prevent BootMenu from
  136. functioning (as expansion memory isn't accessible during the reboot
  137. process).
  138.  
  139. The NTSC/PAL switch code simply alters the mode bit on the 1mb agnus.
  140.  
  141. The expansion board disable code is slightly more artistic - it scans
  142. for exapansion boards waiting to be configured, and either tells them
  143. to shutup (if they support it) or configures them out of the way.
  144. Hence by the time expansion.library gets run there's no boards around
  145. - hence nothing gets configured and added to the system.
  146.  
  147. People who bother to read the included source code will notice it
  148. possible to build a version that will do an AddMem of non-autoconfig
  149. memory on reboot. This was done so as to allow a friend (hi Peter!)
  150. with an old Ronin accelerator board to do a 'fake autoconfig' on his
  151. memory as opposed to being forced to run a cli 'addmem' on every
  152. reboot. As most memory boards are autoconfig nowdays, I haven't
  153. released the executable for that version - but the source code could
  154. be useful for anyone wanting to build a simple memory board. Note
  155. that in the addmem code I set the priority of the ram to -20 to make
  156. sure the 2090a driver uses the chipmem for it's buffers, as the
  157. Ronin memory is NOT capable of being DMA'd to. If your memory does
  158. support DMA, you should raise it's priority to >0 to make the
  159. driver and libraries use it, as this will maximise the amount of free
  160. chip mem you will have after reboot.
  161.  
  162. The program was assembled using Hisoft's DevPac v2 - it should be
  163. fairly simple to alter the code to assemble under other assemblers
  164. however.
  165.  
  166.  
  167. Virus Checkers and BootMenu
  168. ---------------------------
  169.  
  170. As BootMenu hangs around by much the same mechanism as some viruses,
  171. most good virus checkers will give you some warning when run about
  172. ColdCapture and CoolCapture being set and the possibility that this
  173. represents a virus in the system.
  174.  
  175. If you use VMK, you will actually be able to see an embedded message
  176. confirming that the program on cold|coolcapture is only BootMenu,
  177. with other packages your actions may need to be different.
  178.  
  179. If you're at all unsure that what's on the vectors may NOT be
  180. Bootmenu, you should re-run BootMenu, as this will over-write the
  181. vectors and re-install itself, disabling any virus that may have been
  182. using them. Simply clearing the vectors (thru your virus checker)
  183. will disable Bootmenu.
  184.  
  185. As long as you get BootMenu's screens on reboot, you can be 90% sure
  186. no virus is using the coldcapture and coolcapture vectors - however
  187. you should still be cautious, as a virus could pass execution to my
  188. code if it wanted to be clever (haven't yet seen a virus that clever
  189. though!).
  190.  
  191. Also, as some newer viruses stay in memory _without_ using  the
  192. cold/coolcapture vectors, so you should stil run virus checkers!
  193.  
  194. General Info
  195. ------------
  196.  
  197. I would like to thank all the people on AmigaINFO BBS who helped in
  198. beta testing this program, especially Peter.B Mcintyre, John
  199. Nettleton and Stephen Webber, all of whom were always only too
  200. willing to download new test versions at weird hours to help out
  201. with testing the code on differing machine setups.
  202.  
  203. If you have any questions about the program, or bug-reports, feel
  204. free to contact me.
  205.  
  206. The source code and executable are 100% public domain - use or abuse
  207. it as you see fit. If you'd like to use BootMenu on a commercial
  208. package, feel free, though an acknowledgement (or a free copy of the
  209. package!) would be nice!
  210.  
  211. You can contact me via the following routes :-
  212.  
  213. mail on internet/usenet/bitnet/janet et al :
  214.  
  215.      chem194@canterbury.ac.nz
  216.      "meaningful userid's are for wimps" :-)
  217.  
  218. BBS email:
  219.  
  220.      'JOHN DAVIS' on   AmigaINFO BBS
  221.                        ph NZ+3-3371531
  222.                        24 hours a day 1200/2400 baud ccitt
  223.                         (v22/v22bis)
  224.  
  225.  
  226. Snail Mail if you must to:
  227.  
  228.      John Davis
  229.      31 Clarence St
  230.      ChristChurch 2
  231.      New Zealand
  232.  
  233.  
  234. ENJOY!!!
  235.